Hello folks!

This is my first post in this group, and I don't qualify as a C or C++
programmer but I have a suggestion:

The #read directive in POV-Ray follow strict rules, in order to read
variables or strings. I understand why this must be so. But I suggest a new
option that read the content of a text file regardless of the formatting. In
other words, POV-Ray will not try to interpret the file, but only read a
given number of characters into a string. The user can afterwards search the
string for any information they require. Here's an example:


#declare Offset=0; // Start reading at beginning of file
#declare Length=30; // Read 30 characters

#fopen MyFile "mydata.txt" read

   #read_ascii (MyFile, Offset, Length, MyString)

#fclose MyFile



If I wasn't so dumb, I could probably code it myself! I have the Borland C++
builder but not the necessary education. I somehow think it would be easy to
implement the feature, but I'd need a step-by-step guidance, and I don't
expect you to spend time on that. However, the feature would be useful.

Regards,
Hugo

Post a reply to this message

On Thu, 8 May 2003 14:02:27 +0200, "Hugo Asm" <hua### [at] post3teledk> wrote:
> However, the feature would be useful.

Probably, but not universal. '\0' is '\0' :-(

ABX

Post a reply to this message

> > However, the feature would be useful.
>
> Probably, but not universal. '\0' is '\0' :-(

You mean, it's not platform independant? At least this is the only
hinderness I can think of.

If this is what you mean, either a conversion is needed for certain
characters, or such characters need to be removed. If this is troublesome,
perhaps the user can make 3 branches of code in SDL to compensate for
different operating systems. Then SDL should probably have a build-in
variable that tells what system the computer is running.

Regards,
Hugo

Post a reply to this message

Hugo Asm wrote:
> 
> > > However, the feature would be useful.
> >
> > Probably, but not universal. '\0' is '\0' :-(
> 
> You mean, it's not platform independant? At least this is the only
> hinderness I can think of.

No, i think he means if the file contains a '\0' this will result in a
'\0' :-)

'\0' indicates the end of a string so this would mess up the whole thing.

As a general note threads starting with:

> This is my first post in this group, and I don't qualify as a C or C++
> programmer but I have a suggestion:

are usually a bad idea because they tend to contain a specific suggestion
for a feature although this often does not make sense.  You should better
tell what you are trying to achieve and not what you think is the best way
to achieve it.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 28 Feb. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

On Thu, 8 May 2003 14:24:20 +0200, "Hugo Asm" <hua### [at] post3teledk> wrote:
> > Probably, but not universal. '\0' is '\0' :-(
>
> You mean, it's not platform independant?

No. http://www.webopedia.com/TERM/N/null_character.html

ABX

Post a reply to this message

On Thu, 08 May 2003 14:40:17 +0200, Christoph Hormann <chr### [at] gmxde>
wrote:
> You should better
> tell what you are trying to achieve and not what you think is the best way
> to achieve it.

If I can somehow predict intentions I think that image format which read bytes
as gray values into one row image would be similiar solution which preserves 0
value. This could be readed via eval_pigment.

ABX

Post a reply to this message

> If I can somehow predict intentions

No, but thanks for trying. My case deals with all software that outputs a
text file, with some information that could be used in a POV-Ray scene file.
There has been a few occasions where I could easily have written a
"converter" in SDL, if just POV-Ray could read those files. Most recent
example is the following:

1) Other software outputs a mesh2 for POV-Ray.

2) Animation in POV-Ray requires interpolation between sets of mesh2 data
(keyframes in a character animation). I wrote a macro to interpolate the
data.

3) However, I need to manually convert the mesh2 data, into a set of
array's, because otherwise a macro can't read them.

If I could search the mesh2 file, for the right place to begin loading all
the vertex vectors, normal vectors, etc.. this would run automatic. So far I
have to use the copy-and-paste methods, and with a lot of mesh2 input, this
is not very clever. The alternative is to modify POV-Ray, or modify the
other software, to output files that follow the rules of the #read
directive.

But I think the most user-friendly thing to do, is to modify POV-Ray. Most
software cannot output for POV-Ray, even if they can output some text files.
I could write an .obj converter in SDL since this file-format is text based.
I remember a case where someone mentioned a particle-system that runs
independant of POV-Ray, but it's output is text-based and could be converted
in SDL. The user had to manually edit the files.

Convinced?  :o)

Hugo

Post a reply to this message

On Thu, 8 May 2003 15:43:24 +0200, "Hugo Asm" <hua### [at] post3teledk> wrote:
> Convinced?  :o)

I have no idea what version of Windows are you using but look into 'for' command
in dos box (call 'for /?' for parameters). In some Windowses you can perform
loop over lines of text file and probably add quotation marks and commad for
each line to make acceptable file without opening text editor. I used similiar
method when worked on Insert menus for all include files from standard
distribution.

ABX

Post a reply to this message

Hugo Asm wrote:
> 
> [...]
> 
> Convinced?  :o)
> 

No.  You say you need to convert mesh data into a form that POV-Ray can
read as arrays and the only solution should be to modify POV-Ray?

If your mesh2 file is always in the same basic form (i.e. line breaks at
the same positions etc.) a short sed script should be sufficient to
convert it into a set of arrays.

In most cases the compressed mesh (pcm) toolkit:

http://www.geocities.com/SiliconValley/Lakes/1434/pcm.html

should also work for this purpose (although it does not support all mesh2
features IIRC).

Both solutions are very fast and the former is quite easily to adapt to
any special requirements in addition - in one word they are very user
friendly.  Reading a mesh2 file through individual strings with an SDL
program on the other hand would be extremely slow.  

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 28 Feb. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

> I have no idea what version of Windows are you using but look
> into 'for' command in dos box

Thanks, I have lots of Windows in the house, it should be enough. I was
hoping for a more elegant solution though. What happens if I write \0 in a
string? There is probably some conversion to prevent it from ending
prematurely. Perhaps the same conversion could be added in the reading
process and the string would be fine?

Regards,
Hugo

Post a reply to this message